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I.  INTRODUCTION 


The  Access  Line  Engineering  Computer  Package  is  the  aggregation  of 
software  that  is  used  to  analyze  and  resize  the  CONUS  AUTOVON  access  area. 
Previously,  two  methods  have  been  used  to  engineer  the  CONUS  AUTOVON  access 
area:  one  proposed  by  ATaT  Longlines  and  the  other  developed  by  the  Traffic 
Engineering  and  Analysis  Branch  of  the  Defense  Communications  Agency  (DCA). 
Since  the  discrepancies  between  these  two  methods  were  significant,  the 
Traffic  Engineering  and  Analysis  Branch  of  DCA  Headquarters  enlisted  DCEC's 
help  in  standardizing  the  access  area  engineering  methods[l].  Subsequently, 
DCEC  developed  its  own  method  which  appears  more  accurate  than  either  of  the 
two  previous  methods[2]. 

The  Access  Line  Engineering  Computer  Package  is  a  computer  model  that 
incorporates  the  model  developed  by  DCEC  along  with  a  command  list  (CLIST) 
which  ultimately  provides  the  user  with  the  capabilities  of: 

•  Resizing  the  various  PBX's  in  the  CONUS  AUTOVON  access  area. 

•  Editing  data  and  resizing  a  variable  number  of  PBX's  in  the  foreground. 

•  Producing  a  report  that  may  be  used  by  DCA  Headquarters  for  their 
semiannual  report. 

The  steps  of  access  line  engineering  are: 

a.  Load  Determination 

b.  Retry  Adjustment 

c.  System  Sizing. 

The  purpose  of  this  document  is  twofold: 

a.  To  explain  the  various  systems  that  exist  and  how  the  software 
developed  deals  with  these  systems,  and 

b.  To  detail  how  the  software  interacts  with  the  model  through  a  command 
list. 

The  following  section  directly  relates  to  TN  22-61  [2],  which  describes 
the  performance  and  resizing  algorithms  incorporated  in  the  access  area 
engineering  system.  However,  TN  22-81  details  a  complete  analysis  for  only 
one  specific  case.  There  are  presently  nine  different  cases  that  comprise  the 
existing  CONUS  AUTOVON  access  line  configurations.  The  access  area 
engineering  system  possesses  the  capability  of  predicting  the  performance  of 
and  analyzing  any  type  of  configuration  currently  in  the  CONUS  AUTOVON  access 
area. 

The  third  section  details  the  software  that  was  developed  in  this  computer 
package,  that  is,  the  various  computer  programs  used  in  conjunction  with  the 
access  line  engineering  analysis. 

Finally,  section  IV  is  a  summary  of  our  findings  and  the  conclusions  of 
our  study. 


II*  SYSTEM  CONFIGURATIONS  IN  THE  CONUS  AUTOVON  ACCESS  AREA 

The  base  configuration  of  a  typical  CONUS  AUTOVON  access  area  in  the 
Defense  Communications  System  (DCS)  is  shown  in  Figure  1. 


Figure  1.  Typical  CONUS  AUTOVON  Access  Area 
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The  calls  traveling  from  an  AUTOVON  switch  to  the  PBX  are  termed  IN  calls. 

The  calls  trying  to  get  from  the  PBX  to  the  AUTOVON  switch  are  referred  to  as 

OUT  calls.  Typically,  the  IN  calls  first  attempt  to  seize  the  in-only  lines; 
if  all  those  trunks  are  busy  it  will  then  try  to  seize  a  two-way  trunk.  A 

call  that  is  blocked  on  both  of  these  trunk  groups  is  lost.  The  OUT  calls  may 

only  seize  the  two-way  trunks.  In  this  system,  the  IN  calls  have 
accessibility  to  a  greater  number  of  trunks  than  do  the  OUT  calls  and  will 
thus  obtain  a  better  grade  of  service. 

In  order  to  properly  analyze  any  access  area,  as  we  said  in  section  I, 
three  basic  steps  must  be  followed: 

a.  Load  Determination 

b.  Retry  Adjustment 

c.  System  Sizing. 

The  load  determination  step  is  designed  to  obtain  accurate  measurements  of 
both  the  inward  and  outward  traffic  in  the  access  area.  This  traffic  is 
measured  in  erlangs  and  is  called  the  inward  offered  load  ( Pj )  and  the 
outward  offered  load  (P2).  In  the  CONUS  AUTOVON  access  area,  it  became 
readily  apparent  that  there  are  various  combinations  of  system  configurations 
and  available  data.  This  necessitated  the  use  of  alternative  methodologies  in 
the  load  determination  step.  These  methodologies  are  discussed  in  subsection 
1  of  this  section. 

The  retry  adjustment  step  is  needed  to  account  for  the  calls  that  are 
initially  blocked  but  then  tried  again.  The  initial  offered  loads  that 
contain  those  calls  called  retries,  must  be  adjusted  to  account  for  this 
factor. 

The  third  and  final  step  of  the  AUTOVON  access  area  analysis  is  the  system 
sizing  step.  In  this  step,  the  adjusted  loads  are  used  to  determine  the 
current  inward  and  outward  grades  of  service  (percentages  of  calls  being 
blocked  inward  and  outward).  We  then  determine  the  combination  of  in-only, 
out-only,  and  two-way  lines  that  will  meet  a  specified  grade  of  service 
requirement.  One  such  requirement  is  that  the  desired  inward  grade  of  service 
be  P.05  and  the  outward  grade  of  service  be  P.10;  that  is,  5  percent  of  the  IN 
calls  and  10  percent  of  OUT  calls  are  lost. 

As  will  be  shown,  the  retry  adjustment  and  system  sizing  are  the  same  once 
the  IN  and  OUT  loads  are  determined.  The  variations  of  system  configurations 
and  available  data  necessitated  the  development  of  several  methods  to  deal 
with  various  cases  in  determining  the  loads. 

1.  LOAD  DETERMINATION 

As  previously  stated,  the  predominant  type  of  CONUS  AUTOVON  access  area 
system  includes  both  in-only  and  two-way  lines.  We  will  refer  to  this  as  the 
"base  system".  However,  the  base  system  given  may  not  always  include  all  of 
the  possible  data  elements;  therefore,  various  subsystems  arise.  The  known 
data  may  Include  any  (or  all)  of  the  following:  the  total  usage  (in  CCS),  the 
usage  on  the  in-only  lines  (in  CCS),  usage  on  the  two-way  lines  (in  CCS), 
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usage  out  (In  CCS),  peg  count  out  (PCO),  peg  count  in  (PCI),  peg  count  into 
the  two-way  lines  (PCI2W),  and  overflow  (OFL)  all  in  number  of  calls.  There 
are  different  subsystems,  though,  that  incorporate  the  same  load  determination 
techniques  as  one  another.  This  will  be  pointed  out  in  the  description  of 
these  subsystems. 

If  one  defines  a  "subsystem"  to  be  a  configuration  of  channels  along  with 
the  known  data  that  traverses  It,  there  are  presently  eight  subsystems  in  the 
CONUS  AUTOVON  access  area.  The  base  system  consists  of  the  five  subsystems 
which  are  described  in  a.  through  e.  The  other  subsystems  represent  the 
variations  of  both  the  channel  configuration  and  the  given  data. 

The  simplest  cases  for  the  base  system  are  those  which  have  the  property 

of  having  all  of  the  needed  data  known  (PCI2W,  PCI,  OFL,  usage  on  the  two-way 
lines,  usage  on  the  one-way  lines)  and  the  overflow  equal  to  zero.  That  is, 
all  of  the  calls  received  service. 

a.  Subsystem  1:  Base  System  With  Overflow  Equal  to  Zero.  If  the  value 

for  the  peg  count  into  the  two-way  Tines  is  zero,  then  the  blocking  that  the 

one-way  (in  only)  lines  see  (PBINON  ■  PCI2W)  is  zero; 

“pn~ 

thus  all  of  the  IN  traffic  is  being  carried  on  the  in-only  lines.  We  may 
therefore  say  that  the  two-way  lines  are  only  being  used  to  carry  OUT 
traffic.  We  may  then  use  the  usage  figures  for  the  inward  and  outward  load 
determinations  as  follows  (dividing  by  36.0  to  convert  from  CCS's  to  erlangs): 

Inward  Pi  ■  usage  on  one-way  lines  (1) 

36.0  . 

Outward  P2  «  usage  on  two-way  lines  (2) 

36.0  . 

If,  however,  there  is  a  value  other  than  zero  for  the  peg  count  into  the 
two-way  lines  (PBIN0N>0),  then  we  must  find  another  way  to  determine  the  load 
since  the  IN  traffic  is  being  carried  on  both  the  in-only  and  on  the  two-way 
lines.  We  use  a  subroutine  called  PHOER,  which  solves  Erlang's  Loss  Formula 
backwards:  given  the  in  blocking  and  the  number  of  in  channels,  it  determines 
the  inward  load  that  gives  this  blocking. 

Next,  we  must  determine  the  outward  load.  If  we  said  that  the  entire 
usage  on  the  two-way  lines  was  for  OUT  traffic,  we  would  be  estimating  the 
outward  traffic  to  be  too  high  since  the  two-way  lines  carry  both  IN  and  OUT 
traffic.  The  IN  traffic  offered  to  the  two-way  lines  is  the  overflow  from  the 
in-only  lines.  Thus,  we  may  determine  the  outward  load  to  be  the  total  load 
on  the  two-way  lines  minus  the  in  load  on  the  two-way  lines: 

P2  -  usage  on  2-way 


PCI2W  X  Pi. 


(3) 


If  this  determination  for  P2  results  in  a  negative  value  (due  to 
inconsistent  data),  we  must  then  try  to  recalculate  the  outward  load  based  on 
different  information.  There  are  two  possible  recalculations,  depending  on 
whether  the  AUTOVON  switch  is  a  4W5  (four-wire  five)  or  is  either  an  ESS  or  an 
AECO.  This  is  because  the  different  AUTOVON  switches  collect  different  types 
of  data.  If  the  switch  is  a  4W5  type,  we  may  directly  use  the  usage  out  data 
and  conclude: 

P?  -  usaqe  out  (4) 

If  the  switch  is  either  an  ESS  or  an  AECO,  then  the  usage  out  data  is  not 
available.  However,  if  the  total  offered  load  is  defined  to  be  the  total 
usage  (divided  by  36),  then  we  may  take  a  percentage  of  this  value  based  on 
the  peg  counts  to  obtain  the  outward  load  as: 

P?  -  TOTAL  USAGE  X  PCO  (5) 

36.0  PCO  +  PCI  . 

In  this  recalculation,  the  ratio  PC0/(PC0+PCI)  is  the  percentage  of  total 
traffic  that  is  OUT  traffic. 


This  describes  the  base  system  where  all  of  the  possible  data  are  known. 
However,  there  are  cases  in  the  CONUS  AUTOVON  access  area  in  which  all  of  the 
pertinent  information  is  not  known.  Therefore,  the  load  determination  steps 
are  given  for  these  cases.  Let  us  examine  the  base  system  (as  shown  in  Figure 
1)  where  again  the  OFL-O;  however,  we  are  now  without  the  information  about 
the  usage  on  the  in-only  lines. 

b.  Subsystem  2:  Base  System  With  Overflow  »  0  and  Unknown  Usaqe  on  the 
In-Only  LINES  “ 

(1)  Type  4W5  AUTOVON  Switch.  Since  we  do  not  know  the  separate 
usage  on  the  in-only  and  two-way  lines,  we  must  use  the  other  information 
available  in  order  to  determine  the  inward  load.  The  values  for  the  total 
usage  and  usage  out  are  given,  so  we  may  determine  Pi  and  P2  as: 

Pi  -  (TOTAL  USAGE  -  USAGE  OUT)  (6) 

36.0 

Pg  «  Total  Usage  Pi  (7) 

36.0 


(2)  Type  ESS/AECO  AUTOVON  Switch.  Since  the  switch  is  not  a  Type 
4W5,  we  do  not  have  the  usage  out  as  we  did  in  subsystem  2(1).  We  will, 
therefore,  use  the  in  and  out  traffic  ratios  applied  to  total  usage: 


Pi  *  Total  Usaqe 
36.0 


PCI 

PCI  +  PCO  . 


X 


(8) 


The  outward  load  determination  may  be  done  as  in  subsystem  2,  equation  (7) 


P?  «  Total  Usaqe  -  PCI2W  -  Pi. 

36.0  PCI 

c.  Subsystem  3a:  Base  System  with  OFL^O  and  the  Peg  Count 
Two-Way  Lines  is  Known.  This  case  was  discussed  in  TN  22—81  [2].  The  inward 
load  is  determined  as  in  the  second  case  of  subsystem  1  where  the  subroutine 
PHOER  is  used.  This  case,  where  the  overflow  ^  0,  leads  us  to  the  following 
method.  We  use,  as  a  measure  of  the  blocking  on  the  in  only  lines: 

PBINON  ■  Peg  Count  Into  the  Two-Way  Lines 

PCI 

Then  we  use  a  computer  subroutine  that,  from  the  blocking  and  the  appropriate 
number  of  channels  (numbers  of  in  channels  in  this  case),  calculates  the  value 
of  the  load  (inward  load  in  this  case).  However,  it  is  not  as  easy  as  before 
to  determine  As  outlined  in  reference  [2],  we  employ  the  secant  method 
to  find  the  outward  load. 

We  initially  determine  a  starting  value  for  the  outward  load,  P2,  by 
solving  Erlang's  Loss  Formula  in  reverse,  using  the  measured  blocking  on  the 
two-way  lines  (subroutine  PH0VF2).  A  guess  is  then  made  for  P2  by: 

^2  -  h  -  PBINON  X  Pi  (set  P2  -  0.10  if  P2  -  0) 

«■*  A 

and  set  P2  ■  P2  -  0.10. 

We  then  use  the  performance  algorithm,  the  subroutine  ALPERF.  Given  the 
number  of  lines  present  and  the  inward  and  outward  loads,  ALPERF  derives  both 
the  inward  and  outward  grades  of  service,  along  with  the  blockings  on  the 
access  lines. 

Thus,  the  performance  algorithm  ALPERF  is  used  with  the  current  outward 
load  *2  to  derive  a  value  for  the  inward  grade  of  service,  ING0S.  Once 

again,  ALPERF  is  used  with  P2  to  return  an  inward  grade  of  service  value 
ING0S.  We  will  use,  as  a  measure  of  the  overall  inward  blocking, 

INBL0CK  «  0FL 

m 

Now,  the  derivative  is  set  by  using  the  form: 


Therefore, 

DF  .  INGOS  -  In60S 

h  -  ?2 

and  P21  -  1^2  -  (IN&OS  -JNBLOCK) 


set  P2  -  ^2 

We  try  to  match  P21  to  &2  within  a  tolerance  of  0.0001  using  the  above 
process  in  an  iterative  manner.  When  this  is  accomplished,  we  have  found  th 
outward  load  P2. 

The  base  system  has  one  case  remaining:  the  case  when  the  PCI2W  is  not 
given. 

d.  Subsystem  3b:  Base  System  with  OFL^O  and  PCI2W  Unknown.  In  this 
subsystem  our  objective  is  to  match  the  ratio  of  the  carried  outward/i nward 
loads  to  the  ratio  of  the  given  peg  counts  (usages  if  switch  is  4W5) 
outward /inward.  In  addition,  the  variable  that  measures  the  overall  inward 
blocking,  INBLOCK,  should  be  equal  to  the  inward  grade  of  service  that  we 
determine,  INGOS.  Therefore,  a  method  was  developed  that  meets  both  of  these 
requirements  simultaneously.  This  technique  is  an  iterative  process  that 
terminates  when  both  objectives  are  satisfied. 

This  method  uses  two  variables  based  on  the  initial  data,  the  overall 
measured  inward  blocking,  INBLOCK,  and  the  adjustment  factor: 

ADJ  FACTOR  «  USAGE  OUT  for  4W5  Switch 
USAGE  IN 


-  Peg  Count  Out  for  ESS/AECO  Switches 

PCI 


We  may  define  a  variable,  TESTSV,  as  follows: 


TESTSV 


P2  X  (1-0UTG0S) 
PT  7  U-IRGGS) 


This  is  the  ratio  of  the  carried  outward  to  the  inward  loads.  Therefore,  in 
this  method  we  will  strive  to  match: 


(1)  TESTSV  to  ADJ-F ACTOR 

(2)  INGOS  to  INBLOCK. 

The  procedure  begins  with  the  use  of  the  inward  load  that  was  determined 
In  subsystem  4a  as  a  starting  point  for  Pi.  We  formulate  a  guess  for  P2 
as: 


?2  -  Pi  X  ADO-FACTOR. 
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This  multiplication  is  done  to  keep  the  offered  loads  in  the  proper  ratio. 


The  inward  grade  of  service  (IN60S)  is  then  calculated  using  the 
performance  algorithm  ALPERF  with  the  present  values  of  Pi  and  P2.  If  the 
INGOS  and  INBLOCK  are  not  sufficiently  close  (within  O.OOl)  then  set  a 
variable  to  be  equal  to  the  ratio  of  the  carried  traffic: 

GOS-RATIO  -  1-INGOS 
1-0UTG0S 

If  INGOS  is  greater  than  INBLOCK,  the  present  load  produces  too  little 
blocking  (relative  to  INBLOCK)  and  therefore  our  load  figures  are  not  high 
enough;  thus: 

Pi  «  Pi  +  increment  (increment  initially  -  1  erlang) 

P2  -  P2  X  ADJ-FACTOR  X  GOS-RATIO. 

If  INGOS  is  lower  than  INBLOCK,  the  present  load  produces  too  much  blocking 
and  therefore  the  loads  are  too  high;  so: 

Pi  «  Pi  -  increment 

P2  -  Pi  X  ADJ-FACTOR  X  GOS-RATIO. 

We  alter  P2  every  time  we  increment  Pi  to  keep  the  ratio  of  the  loads 
as  constant  as  possible.  As  INGOS  and  INBLOCK  approach  each  other  in  value, 
the  magnitude  of  the  increment  is  decreased. 

Once  INGOS  is  matched  to  INBLOCK,  we  then  try  to  equalize  TESTSV  and 
ADJ-FACTOR,  using  the  loads  determined  in  the  previous  matching.  If  TESTSV 
is  less  than  ADJ-FACTOR,  the  carried  outward/inward  load  ratio  has  not  yet 
achieved  a  high  enough  value;  thus,  we  must  add  to  the  outward  load  and 
subtract  from  the  inward  load: 

Pi  ■  Pi  -  increment 
P2  *  P2  +  increment. 

However,  if  TESTSV  is  greater  than  ADJ-FACTOR,  just  the  opposite  is  true  -  the 
carried  outward /inward  load  ratio  is  too  high;  thus: 

Pi  »  Pi  +  increment 
P2  *  P2  -  increment. 

Once  again,  the  variable  GOS-RATIO  »  1— INGOS  is  set.  Increments  are 

1-OUTGOS 

added  and  subtracted  until  TESTSV  and  ADJ-FACTOR  are  within  5  percent  of  one 
another.  Once  this  5  percent  tolerance  is  met,  the  values  of  INGOS  (which  has 
now  changed  due  to  the  new  loads)  and  INBLOCK  are  again  tested  to  see  if  their 
difference  is  still  bounded  by  0.001.  If  not,  then  we  return  to  the  first 
procedure  of  matching  INBLOCK  and  INGOS.  Ultimately,  we  will  match  both  INGOS 
to  INBLOCK  and  TESTSV  to  ADJ-FACTOR.  If  we  are  unable  to  satisfy  both  tests 


simultaneously,  we  explain  that  the  data  for  this  PBX  cannot  be  processed  and 
this  system  is  flagged  by  the  program. 


This  concludes  the  load  determinations  for  all  of  the  various  subsystems 
of  the  base  system.  In  describing  the  load  determination  steps  for  the 
remainder  of  the  systems,  we  will  -  where  applicable  -  refer  back  to 
techniques  used  in  the  base  system. 

Let  us  now  examine  the  case  where  one-way  out  lines  are  the  only  type  of 
lines  in  the  system. 

e.  Subsystem  4;  One-Way  Out  Lines  Only.  Since  there  are  neither 
in-only  nor  two-way  channels,  it  is  obvious  that  there  is  no  incoming  traffic 
thus  Pi  «  0.  The  outward  load  may  be  determined  by  solving  Erlang's  Loss 
Formula  in  reverse  using  the  subroutine  PH0VF2.  This  subroutine  finds  the 
outward  load,  given  the  peg  count  out  (or  usage  out  for  4W5  switches)  and  the 
number  of  out  lines. 

There  are  also  systems  in  CONUS  AUTOVON  where  there  are  in-only  lines  and 
no  two-way  lines. 

f.  Subsystem  5:  Absence  of  Two-Way  Lines.  The  inward  load  is 
determined  as  in  subsystem  1.  If  there  are  no  out-only  channels,  then  it  is 
clear  (since  there  are  no  two-way  channels)  that  no  out  load  is  possible;  ?2 
»  0.  If  there  are  out-only  lines,  then  the  outward  load  is  determined  as  in 
subsystem  4. 

Additionally,  there  is  a  system  in  CONUS  AUTOVON  where  all  the  lines  are 
two-way  lines.  Once  again,  there  are  various  subsystems  dependent  upon  the 
type  of  AUTOVON  switch  and  the  known  data.  We  will  start  analyzing  this 
system  at  its  simplest,  where  the  overflow  is  zero,  and  the  peg  count  in  is 
zero. 


g.  Subsystem  6:  Only  Two-Way  Lines  With  0FL°0  AND  PCI=0,  and  All 
Pertinent  Data  Known. 

Since  the  peg  count  in  is  zero,  we  have  Pj_  =  0.0.  With  the  total  usage 
being  known,  we  may  easily  determine  ?2  as: 

P?  -  TOTAL  USAGE 
- 30 -  . 

Next,  examine  the  subsystems  where  the  OFL  ^  0  and/or  the  PCI  0. 

h.  Subsystem  7:  Only  Two-Way  Lines  with  PCI  ^  0  or  OFL  4=  0. 

(1)  Type  4W5  AUTOVON  Switch. 


If  PBINON  «  O.O,  this  signifies  that  PCI2W  «  PCI  and  thus  the  peg  count 
data  cannot  be  trusted.  We  therefore  use  ti.^  usage  figures  to  obtain  the 
total  load,  P  TOTAL*  as: 

P  total  -  TOTAL  USAGE  (9) 

36.(5 


This  calculation  for  P  TOTAL  1S  valid  also  when  PBINON  »  1.0  (thus  PCI2W- 
PCI)  and  the  overflow  is  zero. 


If  PBINOU  (blocking  on  two-way  lines) 


OFL  +  0 
PCI2W 


then  there  is  overflow  in  (blocking)  the  system. 

If  PBINON  »  1.0  when  there  is  overflow,  then  we  may  again  (using  PHOER) 
solve  Erlang's  Loss  Formula  in  reverse  (using  PBINOU)  to  solve  the  total 
load.  An  additional  case  that  is  handled  by  using  PHOER  is  the  subsystem  in 
which  PBINON  is  neither  1  nor  0  (we  must  use  the  subroutine  since  the  peg 
count  data  alone  is  not  sufficient  to  determine  PTOTAL). 

In  all  the  cases  of  subsystem  7(1),  the  total  load  is  now  split  into  the 
inward  and  outward  components  via  the  usage  data: 

Pi  ■  (total  usage  -  usage  out)  X  P  TOTAL 
total  usage 

p2  -  p  TOTAL  -  pl- 

(2)  Type  ESS/AECO  AUTOVON  Switch.  If  the  overflow  -  0,  then  the 
total  load  is  determined  as  in  subsystem  7(1),  equation  (9).  If  the  overflow 
+  0,  then  the  total  load  is  determined  by  using  the  subroutine  PHOER. 

Once  again,  since  we  have  determined  the  total  offered  load,  we  need  to 
determine  the  inward  and  outward  components.  We  split  the  load  by  taking  a 
percentage  of  the  total  load  based  on  peg  counts: 


Pi  -  PCI  X 

PCI '+  PCO 


p  TOTAL 


p2  »  p  TOTAL  -  pl- 

i.  Subsystem  8.  All  Three  Types  of  Lines  Present  (In-Only,  Out-Only, 
Two-Way). 

Finally,  there  is  the  system  where  all  three  types  of  lines  are  present  - 
in-only,  out-only,  and  two-way  lines.  In  CONUS  AUTOVON,  there  are  very  few 
cases  of  this  type,  and  they  basically  split  into  two  subsystems: 

(1)  All  Three  Types  of  Lines  with  PCI2W  Known.  The  inward  load  is 
determined  in  exactly  the  same  way  as  it  was  for  the  base  system  subsystem  1. 
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The  outward  load  Is  determined  In  the  same  way  as  It  was  for  the  out-only 
system,  subsystem  4. 

(2)  All  Three  Types  of  Lines  with  PCI2W  Unknown.  If  the  PCI2W  is 
unknown,  then  we  are  dealing  with  a  system  very  similar  to  the  base  system 
where  the  PCI2W  is  unknown.  Therefore,  both  the  in  and  out  loads  are 
determined  as  In  subsystem  3b  of  the  base  system. 

2.  RETRY  ADJUSTMENT 

It  is  necessary  to  account  for  calls  that  are  initially  blocked  but  do  not 
leave  the  system.  These  calls  are  called  retries  (or  reattempts).  The 
initial  offered  loads  that  were  determined  must  be  reduced  so  that  we  have  an 
accurate  measure  of  the  traffic.  Therefore,  both  the  inward  and  outward  loads 
are  adjusted  to  account  for  this  retry  factor  through  the  use  of  engineering 
constants  [2]. 

However,  this  initial  adjusted  out  load  must  be  readjusted  depending  on 
the  outward  grade  of  service  that  is  desired.  Thus,  if  we  are  resizing  (final 
step)  for  a  P.10  out  then: 

adjusted  outload  «  initial  adjusted  outload  (1  +  0.6  x  PBOUT*) 
where  PBOUT*  is  the  desired  out  grade  of  service  (P.10  in  this  case). 

As  explained  in  the  next  section,  there  is  one  additional  resizing  grade 
of  service  requirement,  that  of  P.05  inward  without  regard  to  the  outward 
grade  of  service.  Thus,  for  this  case,  we  arrive  at  the  adjusted  outload  by 
multiplying  by  the  final  outward  grade  of  service  realized: 

adjusted  outload  ■  initial  adjusted  outload  (1  +  0.6  x  final  OUTGOS). 

3.  SYSTEM  SIZING 

This  is  the  final  step  of  the  CONUS  AUTOVON  access  area  analysis.  The 
sizing  involves  the  use  of  the  performance  algorithm  ALPERF.  Using  the 
adjusted  loads,  and  the  current  system  configuration,  we  use  ALPERF  to  examine 
the  current  grades  of  service.  The  sizing  basically  entails  the  adding  or 
subtracting  of  channels  (in-only  and  two-way  lines)  until  the  desired  grades 
of  service  are  met.  There  are  two  sizing  methodologies  which  were 
incorporated: 

a.  Maximize  the  total  carried  traffic  and  achieve  a  desired  blocking  on 
the  in-only  lines  while  meeting  the  grades  of  service  requirements. 

b.  Maximize  the  IN  traffic  and  minimize  the  total  number  of  channels 
while  meeting  the  grades  of  service  requirements. 

The  three  grades  of  service  requirements,  which  are  required  for  the  final 
document,  are  presented  in  the  following  subparagraphs: 


a.  P.05  In/P. 10  Out.  This  GOS  requires  that  we  design  the  system  so 
that  the  PBX  experiences  blockage  of  no  more  than  5  percent  of  its  incoming 
calls  and  10  percent  of  Its  outgoing  calls.  Thus,  the  new  system  we  have 
designed  will  have  the  configuration  necessary  to  insure  the  P. 05/P. 10 
requirement. 

After  resizing  for  P. 05/P. 10,  an  additional  sequence  of  tests  are  also 
executed.  These  “grades  of  service  tolerance"  tests  involve  removing  one 
two-way  line  from  our  designed  reconfiguration,  and  using  ALPERF  to  determine 
the  new  "inward  and  outward"  grades  of  service. 

Two  tests  are  then  performed: 

If  TRIAL  INGOS  -  0.05 _ <0.30 

TRIAL  INGOS  -  Reconfigured  INGOS 

and  TRIAL  OUTGOS  -  0.10  <  0.30 

TRIAL  OUTGOS  -  Reconfigured  OUTGOS 

then  we  accept  the  trial  configuration  as  the  recommended  system.  In  effect, 
we  are  seeking  to  approximate  the  P. 05/P. 10  requirement,  and  the  subtraction 
of  one  line  may  leave  us  sufficiently  close  to  this  requirement  in  some  cases. 

b.  P.05  In/P. XX  Out.  This  case  is  only  studied  when  the  initial  INGOS 
is  worse  than  0.05.  This  requirement  says  we  are  designing  the  system  to 
possess  a  P.05  GOS  inward,  without  regard  to  the  value  of  the  outward  grade  of 
service.  This  objective  is  achieved  by  continually  adding  to  the  original 
number  of  in-only  lines  (one  at  a  time)  until  the  inward  GOS  of  P.05  is  met, 
while  leaving  the  number  of  2-way  lines  the  same.  The  final  value  of  the 
OUTGOS  is  determined  by  calling  ALPERF  when  the  P.05  GOS  is  met.  Since  only 
the  INGOS  is  crucial  here,  only  the  first  "grade  of  service  tolerance"  test 
(for  INGOS)  is  used. 


c.  P.05  In/P. 20  Out.  This  grade  of  service  requirement  is  only  studied 
when  the  initial  configuration  possesses  an  outward  grade  of  service  worse 
than  P.20.  We  then  resize  the  access  area  to  achieve  P. 05/P. 20.  As  in  the 
P. 05/P. 10  objective,  we  examine  the  resized  configuration  in  terms  of  its 
"grades  of  service  tolerance"  tests.  The  only  difference  is  that  P.20  is  used 
as  our  initial  OUTGOS  in  our  tests  (instead  of  P.10). 


III.  SOFTWARE 


Seven  software  programs  and  two  IBM  utilities  were  used  in  conjunction 
with  the  Access  Line  Engineering  Computer  Package: 

Software  Programs 

(1)  PPACC1 

(2)  AGGREG 

(3)  MATCH 

(4)  SETDATA 

(5)  SIZING 

(6)  MAXTRAF 

(7)  FORMAT 

IBM  Utilities 

(1)  IEBGENER 

(2)  SORTD 

1.  DATA  PREPARATORY  SOFTWARE 

The  first  problem  encountered  in  using  the  Access  Line  Engineering 
Computer  Package  was  that  of  the  structure  of  the  original  data  provided  by 
ATT.  The  format  of  this  information  is  complex  and  nonuniform.  In  fact, 
before  any  analysis  could  be  attempted,  it  was  necessary  to  properly  aggregate 
and  format  this  data.  Thus,  two  software  program,  PPACC1[3]  and  AGGREG,  were 
developed. 

PPACC1  is  designed  to  read  the  initial  ATT  data  base  (one  month  of  data) 
and  to  delete  any  headings  or  nonessential  information  that  is  present. 
Therefore,  only  the  necessary  data  elements  are  left  after  PPACC1,  in  terms  of 
either  identification  or  computational  value. 

However,  the  data  that  relates  to  one  PBX  may  physically  exist  on  distinct 
records  in  the  data  base.  It  was  then  decided  that  in  order  to  properly 
analyze  the  access  area,  the  data  would  have  to  be  aggregated;  the  AGGREG 
program  aggregates  and  structures  the  data.  The  software  becomes  quite 
detailed  due  to  the  numerous  different  "hunting  schemes"  of  different  switches 
along  with  different  system  configurations.  As  an  example,  there  are 
completely  different  hunting  sequences  for  ESS,  AECO,  and  4W5  switches.  In 
turn,  for  different  configurations  within  each  switch  there  are  different 
aggregation  policies.  Therefore,  AGGREG  is  a  case-by-case  testing  of  the  PBX 
in  order  to  ascertain  its  proper  data  aggregation. 

The  third  program  to  be  implemented  was  MATCH,  developed  to  select  PBX's 
from  the  ATT  data  base  which  DCA  desires  to  study.  These  were  placed  in  a  DCA 
data  base.  In  addition,  the  DCA  data  base  was  corrected  with  respect  to  the 
PBX  location  names  and  phone  exchanges. 

The  final  preparatory  program  developed  was  SETDATA.  This  was  developed 
to  combine  several  months  of  data  into  one  common  data  base.  Thus,  one  may 


analyze  several  months  of  data  simultaneously  by  formulating  arithmetic 
averages.  The  resulting  output  of  this  software  is  a  new  data  base  with 
average  values  for  every  P6X  to  be  studied  in  the  CONUS  AUTOVON  access  area. 

2.  ANALYSIS  SOFTWARE 

The  tools  for  the  analysis  are  located  in  the  program  modules  SIZING  and 
MAXTRAF.  These  modules  offer  two  different  approaches  to  the  resizing 
philosophy,  but  are  identical  in  their  load  determination  steps.  Thus, 
depending  on  the  user's  needs,  the  user  may  select  either  module. 

The  software  for  both  of  these  modules  comprises  three  basic  sections. 

The  initial  section  checks  the  data  for  its  validity  and  completeness.  If  the 
data  are  insufficient  or  incorrect,  the  PBX  is  identified  and  printed  without 
any  further  computations. 

The  second  section  calculates  the  inward  and  outward  offered  loads  for  the 
PBX  being  studied.  Due  to  the  large  number  of  different  systems,  the  coding 
of  this  section  is  detailed.  In  addition,  the  offered  loads  are  reduced  to 
account  for  retries  -  calls  that  were  initially  blocked  but  do  not  leave  the 
system. 

The  third  section  is  that  part  of  the  code  which  is  responsible  for  the 
engineering  of  the  present  access  area.  Two  sizing  philosophies  were 
studied.  The  program  SIZING  implements  the  philosophy  of  maximizing  the  total 
traffic  and  achieves  a  desired  blocking  on  the  in-only  lines  while  meeting  the 
desired  inward  and  outward  grades  of  service.  The  program  MAXTRAF  implements 
the  philosophy  of  maximizing  the  total  incoming  traffic  (incoming  to  PBX)  and 
minimizing  the  total  number  of  channels  while  meeting  the  desired  inward  and 
outward  grades  of  service. 

The  program  FORMAT  was  used  to  construct  the  layout  of  the  semiannual 
report,  as  requested  by  the  Traffic  Engineering  and  Analysis  Branch  of  the  DCA. 

The  IBM  utilities  IEBGENER  and  SORTD  were  used  to  trarlsfer  data  from  tape 
to  disc  and  to  sort  the  data. 
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IV.  SIGNIFICANT  FINDINGS  AND  CONCLUSIONS 


In  September  1981,  DCA  Headquarters  published  Its  semiannual  access  area 
engineering  report.  Those  PBX's  that  were  engineered  by  DCA  Headquarters  were 
also  studied  at  DCEC  by  means  of  the  Access  Line  Engineering  Computer 
Package.  In  fact,  DCA  Headquarters  has  expressed  great  satisfaction  with  this 
automated  system.  The  amount  of  time  needed  to  do  this  task  has  been  greatly 
reduced  by  this  automated  system.  It  is  now  possible  by  submitting  one 
computer  run  (or  two  smaller  runs)  to  completely  analyze  the  entire  CONUS 
AUTOVON  access  area  in  less  than  three  minutes  of  CPU  time. 

In  addition,  the  incorporation  of  the  interactive  CLIST,  EDIT1  in  the 
Access  Line  Engineering  Computer  Package  permits  resizing  PBX's,  editing  data, 
and  producing  a  report  usable  by  DCA  Headquarters  for  their  engineering  report. 
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